The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. As the number of basic applications, and the media which it is possible to combine, increases, so will the number of services offered to the end users, giving rise to a new generation of personalised, rich multimedia communication services. The IMS is defined in the 3GPP Specification 23.228.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS 3 fits into the mobile network architecture in the case of a GPRS/PS access network. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer, or traffic plane and through which signals are directed to/from user terminals accessing the network. The GPRS network includes various GPRS Support Nodes (GSNs) 2a, 2b. A gateway GPRS support node (GGSN) 2a acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). A Serving GPRS Support Node (SGSN) 2b keeps track of the location of an individual Mobile Terminal and performs security functions and access control. Access to the IMS 3 by IMS subscribers is performed through an IP-Connectivity Access Network (IP-CAN). In FIG. 1 the IP-CAN is a GPRS network including entities linking the user equipment to the IMS 3 via the connectivity layer 1.
The IMS 3 includes a core network 3a, which operates over the Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 include Serving CSCFs (S-CSCF) and Proxy CSCFs (P-CSCF), which operate as SIP proxies within the IMS in the middle, Control Layer.
At the top is the Application Layer 6, which includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality. Application Servers 7 provide services to end-users on a session-by-session basis, and may be connected as an end-point to a single user, or “linked in” to a session between two or more users. Certain Application Servers 7 will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server 7).
IMS relies on Internet Protocol (IP) as a transport technology. Using IP for voice communications, however, presents some challenges, especially in the mobile community where Voice Over IP (VoIP) enabled packet switched (PS) bearers may not always be available. To allow operators to start offering IMS-based services while voice enabled PS-bearers are being built out, the industry has developed solutions that use existing Circuit Switched (CS) networks to access IMS services. These solutions are referred to as IMS Centralized Services (ICS). ICS is also the name of the Work Item in 3GPP Release 8 addressing these matters.
Currently, ICS contains three alternative solutions known as I1-CS, I1-PS and “N-ICS”. N-ICS is a solution in which the network implements an adaptation function between a Global System for Mobile Communications (GSM) terminal and the IMS system. The terminal is not required to have any special functionality, but the CS network requires an update with new functionality in Mobile Switching Centres (MSC)/Visitor Location Registers (VLRs).
I1-CS and I1-PS both require ICS functionality in an accessing terminal. The CS network is on the other hand unaffected and transparent to the communication taking place between the ICS capable terminal and an IMS network. IMS CS Control Protocol (ICCP) is a control protocol standardized in 3GPP to allow an ICS capable terminal to communicate with service implementations in an IMS network when a CS network is used as a transport network. It is used for mid-call signalling for services such as call hold and call waiting. Unstructured Supplementary Services Data (USSD) carries the ICCP protocol transparently from an ICS terminal through the CS network to an “IMS-Adapter” that translates ICCP into SIP. The IMS-Adapter is a new functional entity in the IMS network, termed an IMS CS Control Function (ICCF).
A difference between I1-CS and I1-PS is that I1-PS uses SIP signalling over a PS access network for all ICS related signalling. This includes mid-call manipulations (for example hold/retrieve, Explicit Call Transfer), the addition of non-speech media to an existing call, IMS Registration, and so on. I1-CS, on the other hand, uses the CS (ICCP over USSD) access network for some purposes such as mid-call manipulations but not for other actions such as IMS Registration, the addition of media to calls, and multiparty calls.
FIG. 2 herein illustrates signalling principles for the I1-CS solution. A terminal 8 is shown that connects to an IMS network 3 via a PS access network 9 and a CS access network 10. Signalling from both access networks traverses an ICCF 11 in the IMS network 3. For both I1-CS and I1-PS, the PS access network 9 is either not suitable for, or not allowed to carry speech (shown as limited capability in FIG. 2), but suitable for SIP signalling. If the signalling takes place simultaneously with a CS voice call, Dual Transfer Mode (DTM) capabilities (the ability to have PS and CS bearers simultaneously in 2G (GSM/EDGE)) are required.
The two different signalling sessions shown in FIG. 2 relate to the same call and should be presented to a remote end (another terminal) as a single session. A problem with dividing signalling over two protocols and access networks is that it can be difficult to correlate each set of signals to one another. Nodes within the IMS network should be able to match signalling sent over a PS access network with signalling sent over a CS access network when the two sets of signalling relate to the same communication or session.